<html>
  
  <head>
    <title>D4L Design Document</title>
  </head>
  
  <body>
    
    <h1>D4L Design</h1>
    
    <h2>Overview</h2>
    
    <p> System ostensibly consists of four tools: </p>
    
    <ul>
      <li>the course outline tool is essentially a form that
	allows the entry of an overview of the course
	including course aims, learning targets and
	keywords. </li>
      
      <li>the resources tool provides the user with a first
	pass at allocating hours to type of activity and hours
	to staff. </li>
      
      <li>the calendar tool allows users to distribute
	resources to different days </li>
      
      <li>the session planning tool allows the user to flesh
	out calendar entries to real activities that are
	mapped to topics </li>
    </ul>
    
    <h2>Requirements</h2>
    
    <ul>
      <li>A course consists of one or more modules which may
	or may not be ordered.</li>
      
      <li>A module consists of one or more learning
	outcomes.</li>
      
      <li>A module consists of one or more sessions.</li>
      
      <li>A session utilises one or more teaching
	methods.</li>
      
      <li>A session contributes to one or more learning
	outcomes (corresponding to those specified for the
	module)</li>
      
      <li>A teaching method is mapped to one or more
	different cognitive_activities such as attending,
	investigating, discussing, etc.</li>
      
      <li>A teaching method is mapped to three overhead_multipliers,
      one for each of preparation, production and presentation </li>
    </ul>
    
    <h2>Table Descriptions</h2>
    
    <dl>
      
      <dt>assessment</dt>

      <dd>An assessment for a particular module. Assessments for a
	module are ordered. An assessment has a title and a
	description and also a type (see assessment_type).</dd>


      
      <dt>assessment_type</dt>
      
      <dd>A type of assessment. This would be hard-coded to a small
	set such as essay, project report, design, short-answer, test,
	etc.</dd>



      <dt>calendar</dt>
      
      <dd>A specification of which weeks contribute different types of
      hours to teaching methods. This table will be used as the basis
      for the calendar tool.</dd>
      


      <dt>cognitive_activity</dt>
      
      <dd>A cognitive_activity of the learner. Currently:
	attending, investigating, discussing, practising,
	articulating.</dd>
	
	
	
      <dt>course</dt>
      
      <dd>A course. Currently this just has a name and an indication
      as to whether its modules are ordered or not.</dd>
      
      
      
      <dt>course_module</dt>
      
      <dd>Maps a course to zero or more modules. The sequence number
      is only used if the course has modules ordered.</dd>
      
      
      
      <dt>group_size</dt>
      
      <dd>The size of a group for a 'contact' teaching method on a
      particular module. The system would ensure that only teaching
      methods with type=contact are used in this table. Assumption:
      this group size is the same (say) for all seminars. </dd>
      

      
      <dt>hours_type</dt>

      <dd>The type of an hours amount. This will be hard-wired to
      student contact hours, student study hours, academic staff hours
      and support staff hours.</dd>



      <dt>method_activity</dt>
      
      <dd>The (cognitive) activity of a particular
	(teaching) method. This table is used to specify which
	cognitive activities are appropriate to which teaching
	methods.</dd>
      


      <dt>method_activity_time</dt>
      
      <dd>The amount of time specified by the teacher that a
      particular teaching method on a particular module leads to a
      certain type of cognitive activity. This table references the
      method_activity table, thus restricting specification of these
      times to the contents of that table.</dd>

      

      <dt>module_hours</dt>
      
      <dd>A table specifying how many hours of different types it
      involves. These are a priori values specified by the teacher and
      used for checking elsewhere in the system.</dd>



      
      <dt>module_outcome</dt>
      
      <dd>Maps a module to zero or more outcomes.</dd>
      
      
      
      <dt>module_session</dt>

      <dd>Maps a module to zero or more sessions.</dd>
      
      

      <dt>outcome</dt>

      <dd>An outcome has a type (through reference to the outcome_type
      table) and a description.</dd>
		


      <dt>outcome_type</dt>

      <dd>An outcome type just has a description for
      now. e.g. knowledge, understanding, analysis, synthesis,
      evaluation</dd>
		

      
      <dt>overhead</dt>

      <dd>An overhead. Currently preparation, production and
      presentation.</dd>
	


      <dt>overhead_multiplier</dt>
      
      <dd>A multiple for an overhead as specified by the teacher for a
      particular teaching method on a particular module </dd>
		


      <dt>session</dt>

      <dd>At the moment, a session just has a name.</dd>
		


      <dt>session_outcome</dt>

      <dd>Maps a session to one or more outcomes. Note that this maps
      to the module_outcome table. The system will have to enforce
      that if module A consists of session B then the outcomes of
      session B can only be those outcomes associated with module
      A.</dd>



      <dt>teaching_method</dt>

      <dd>A method of teaching such as lecture, seminar, video
      conferening, etc.  For moment, is not editable by teacher. A
      teaching method has a type which can be either 'contact' or
      'study' indicating whether they contribute to contact time or
      study time. Assumption: a teaching method contributes to one and
      not the other. Assumption: there are only two types of teaching
      method (contact and study).</dd>
		
		
      
    </dl>
    
	
</body>
</html>
